Self-authorizing token

ABSTRACT

Self-authorizing tokens are disclosed. Typical embodiments employ a secure element and a secure element interrogator. Such tokens may be used for authorization of financial payments and other secure transactions. In some embodiments the secure element is provisioned with information about a particular payment card holder account. A secure element reader interrogates the smart element and derives information needed to authorize a transaction. In some embodiments the secure element and the secure element interrogator communicate using communications formatted according to ISO 7816-4.

CROSS REFERENCES TO RELATED APPLICATIONS

This application is a Continuation of currently pending and allowed U.S.patent application Ser. No. 12/019,318 filed Jan. 24, 2008, entitled“Self-Authorizing Devices.” This Application and U.S. patent applicationSer. No. 12/019,318 claim priority from and are related to U.S.Provisional Patent Application Ser. No. 60/897,110 filed Jan. 25, 2007,entitled: “Method and Apparatus for Self-swiping Smartcard Payments,”and this patent application and U.S. patent application Ser. No.12/019,318 claim priority from and are related to U.S. ProvisionalPatent Application Ser. No. 60/932,704 filed Jun. 1, 2007, entitled:“Method and Apparatus for a Self-swiping Smartcard.” Provisional PatentApplication Ser. Nos. 60/897,110 and 60/932,704 are incorporated byreference in their entirety herein.

FIELD

This invention relates to the field of devices configured to authorizetransactions using secure element microchips. More particularly, thisinvention relates to tokens that contain secure element microchips andare configured to authorize financial transactions over the internet.

BACKGROUND

In some payment technologies such as smartcards, a microchip referred toas a “Secure Element” (SE) is embedded into the payment card, thepayment fob, or another other device that may be used for makingpayments. In order to extract information from the SE, an interrogator,also referred to herein as a “reader”, is required to interactelectrically with the SE. The reader typically follows standards setforth by the International Organization for Standardization (ISO) orproprietary standards established by financial institutions or otherapplication providers. In addition to making payments such devices maybe used for other purposes such as controlling access to networks anddatabases and verifying identity. Such devices typically employsophisticated technologies for enhancing the security of thesetransactions and preventing fraud. However, the use of the internet isbecoming more popular for such purposes. What are needed therefore aredevices and methods that adapt the enhanced security and fraudprevention techniques used in smartcard systems for use ininternet-based transactions.

SUMMARY

The present disclosure provides, in one embodiment, a token that has amounting structure having a communication connector configured toconnect to a computer terminal. In this embodiment a secure element isaffixed to the mounting structure, and the secure element includes adata file. This embodiment further includes a secure elementinterrogator that is affixed to the mounting structure and that isconfigured to interrogate the secure element to acquire transactioninformation from the data file by exchanging a plurality of transactiondata communications only between the secure element and the secureelement interrogator. This embodiment further includes a communicationscontroller that is affixed to the mounting structure and that isconfigured to receive the data from the secure element interrogator andto transmit the transaction information as a single data communicationto the computer terminal through the communications connector.

Another embodiment provides a token that has a mounting structure havinga communication connector configured to connect to a computer terminal.This embodiment further includes a secure element that is affixed to themounting structure, and the secure element has a payment cardapplication and a data file. Further, this embodiment includes a secureelement interrogator that is affixed to the mounting structure and thatis configured to interrogate the secure element to acquire transactioninformation from the data file by exchanging a plurality of transactiondata communications only between the secure element and the secureelement interrogator. The embodiment also includes a communicationscontroller that is affixed to the mounting structure and that isconfigured to receive the data from the secure element interrogator andto transmit the transaction information as track data to the computerterminal through the communications connector.

A further embodiment provides a token that has a mounting structurehaving a communication connector configured to connect to a computerterminal. There is a secure element that is affixed to the mountingstructure, and the secure element has a data file. In this embodiment asecure element interrogator is affixed to the mounting structure and thesecure element interrogator is configured to interrogate the secureelement to acquire transaction information from the data file byexchanging a plurality of transaction data communications only betweenthe secure element and the secure element interrogator. This embodimentfurther provides a communications controller that is affixed to themounting structure and that is configured to receive the data from thesecure element interrogator and that is configured to transmit thetransaction information to the computer terminal through thecommunications connector.

A further embodiment provides a token that has a mounting structurehaving a communication connector configured to connect to a computerterminal. This embodiment includes a secure element that is affixed tothe mounting structure, and the secure element has a data file. There isa secure element interrogator that is affixed to the mounting structureand that is configured to interrogate the secure element to acquiretransaction information from the data file by exchanging at least onetransaction data communication only between the secure element and thesecure element interrogator. Further included in this embodiment is acommunications controller that is affixed to the mounting structure andthat is configured to receive the data from the secure elementinterrogator and to transmit the transaction information as a singledata communication to the computer terminal through the communicationsconnector.

In another embodiment a token has a mounting structure that has acommunication connector configured to connect to a computer terminal.There is a secure element that is affixed to the mounting structure, andthe secure element includes a payment card application and a data file.There is a secure element interrogator that is affixed to the mountingstructure and that is configured to interrogate the secure element toacquire transaction information from the data file by exchanging atleast one transaction data communication only between the secure elementand the secure element interrogator. Further provided in this embodimentis a communications controller that is affixed to the mounting structureand that is configured to receive the data from the secure elementinterrogator and to transmit the transaction information as track datato the computer terminal through the communications connector.

Another embodiment provides a token that has a mounting structure havinga communication connector configured to connect to a computer terminal.There is a secure element affixed to the mounting structure, and thesecure element includes a data file. There is a secure elementinterrogator affixed to the mounting structure and the secure elementinterrogator is configured to interrogate the secure element to acquiretransaction information from the data file by exchanging at least onetransaction data communications only between the secure element and thesecure element interrogator. Further provided is a communicationscontroller that is affixed to the mounting structure and that isconfigured to receive the data from the secure element interrogator andthat is configured to transmit the transaction information to thecomputer terminal through the communications connector.

BRIEF DESCRIPTION OF THE DRAWINGS

Various advantages are apparent by reference to the detailed descriptionin conjunction with the figures, wherein elements are not to scale so asto more clearly show the details, wherein like reference numbersindicate like elements throughout the several views, and wherein:

FIG. 1 is a drawing of one embodiment of a self-swiping card with a USBinterface.

FIG. 2 is a drawing of a close up view of the USB interface connector onone embodiment of a self-swiping card.

FIG. 3 is a drawing of the internals of one embodiment of a self-swipingcard.

FIG. 4 illustrates a circuit board schematic according to oneembodiment.

FIG. 5 illustrates a system where a self-swiping card is used to delivertrack 1 and track 2 data to a merchant remotely via the internet.

FIGS. 5.1 and 5.2 illustrate interaction and data exchange between aninterrogator chip and an SE.

FIG. 5.3 illustrates a method of encrypting data.

FIG. 6 illustrates one embodiment of an online web form with anauto-populating field for a self-swiping card.

FIG. 7 illustrates the decrypted track data that was encoded within theinformation that came from the auto-populating field from FIG. 6.

FIG. 8 illustrates an embodiment of a self-swiping card with a USBinterface.

FIG. 9 illustrates a further embodiment of a self-swiping card with aUSB interface.

FIG. 10 illustrates an embodiment of the smart card module embedded inthe card.

FIGS. 11A and 11B illustrates embodiments of a self-swiping card in amini-SD and an SD form factor.

FIG. 12 illustrates a system where track 1 and track 2 data with anencrypted PAN (Personal Account Number) data are delivered via theworld-wide web.

FIG. 13 illustrates a method of encrypting PAN digits that maintains theoriginal bank routing code.

FIGS. 13.1-13.4 illustrate elements of an encryption algorithm.

FIG. 14 illustrates a system where a reader on card is queried as analternative to keyboard input.

FIGS. 15 and 15.1 illustrate an embodiment of an online web form with anauto-populating field.

FIGS. 16 and 16.1 illustrate a mobile phone embodiment.

FIG. 16.2 illustrates and encryption technique.

DETAILED DESCRIPTION

In the following detailed description of the preferred embodiments,reference is made to the accompanying drawings, which form a parthereof, and within which are shown by way of illustration the practiceof specific embodiments of self-authorizing smart tokens and embodimentsof self-authorizing cellular network adapters. It is to be understoodthat other embodiments may be utilized, and that structural changes maybe made and processes may vary in other embodiments.

For the purpose of simplifying language and providing a convenientexample, the device that houses a secure element (SE) microchip istypically referred to herein as a “card” or “card device.” It isimportant to note that the “card” or “card device” may not physicallyresemble the shape or size of a typical payment card and may come invarious alternate form factors such as fobs, cartridges, or dongles, orform factors that resemble removable digital memory media such as securedigital (SD) chips. The term “token” is used to encompass all of theseform factors and the term “smart token” refers to a token that includesan SE. Each token has a mounting structure such as substrate (for carddevices) or a packaging case (for fobs, cartridges, and dongles or SDchips).

In many embodiments described herein a card is configured to interactwith a computer terminal. As used herein a computer terminal refers to apersonal computer or a special-purpose terminal provided at a point ofsale or public kiosk. For the purpose of simplifying language andproviding a convenient example the term “PC” (referring to a personalcomputer) will be used as an example of a computer terminal. Typicallythe PC has access to an internet. As used herein the term internetincludes the world-wide web as well as any other public or proprietarynetwork that may be used for authorizing transactions.

In addition to applications involving computer terminals, embodimentsare provided for mobile phones and personal digital assistants (PDAs)that communicate over a cellular network. Such mobile phones and PDAsare referred to herein as cellular network devices. The term “cellularnetwork adapter” is used herein to describe a system that includes in asecure element (SE) microchip for use in a cellular network device. Ofparticular interest are cellular network devices that are configured forauthorization of financial transactions over a network. Typically thecellular network device includes a web browser that is configured forauthorization of a financial transaction over the world-wide-web.However in some embodiments the browser may connect to a differentpublic network or to a proprietary network. In some embodiments thecellular network device may connect to a dialup voice network and thecellular network device may be configured for authorization of afinancial transaction over the voice network, such as by transmission ofDTMF tones or by other encoding.

As previously indicated, in order to extract information from an SE, aninterrogator or “reader” is used to interact electrically with the SE.Because readers are not typically part of most PCs, it is verybeneficial to place the reader functionality on the card device andtranslate information from the SE into a data stream format such as aUSB (Universal Serial Bus) that PCs are generally capable of processing.Other convenient translated formats include software application output,text messaging (e.g., short message service (SMS)), and email messaging.It is particularly advantageous to configure the card devices for HID(Human Interface Device) keyboard emulation for inputting a form fieldor fields on an application running on the PC. It is also verybeneficial to place the reader functionality in the cellular networkadapter and translate information into a data stream that may be sentover the cellular network by the cellular network device.

As used herein the term “host device” is used to refer to either (a) thecomputer terminal that receives the information from a card device or(b) the cellular network device that receives the information from thecellular network adapter.

A significant advantage of extracting and delivering the data within acard device or cellular network adapter is the ability to know beyondreasonable doubt that the data string being delivered over the internetindeed came from a particular SE. This knowledge creates a more securetransaction with lower risk to the merchant, card issuing bank, and cardassociations.

Heretofore the most secure methods for assuring the validity of anelectronic transaction has involved extracting information from abanking card by of swiping the magnetic stripe through a magnetic stripereader, or extracting the information from a smartcard with a separatecontact or contactless reader connected to a point of sale terminal(POS). These methods are known as “card-present transactions.” Becauseof their enhanced level of confidence in validity these methods allow amerchant to receive a discounted transaction fee for that particulartransaction. An example of a less secure transaction is reading orentering account numbers, expiration dates, and card verification codesfrom a card in a phone call or with on-line internet ordering. Thesetransactions are known as “card not present transactions” and incur afull transaction fee.

Preferred embodiments provided herein provide for incorporating a readeron a card device or within a cellular network adapter to extract anddeliver banking track data that were generally not previously possiblebecause of the inability to extract information from the SE or from amagnetic stripe at a computer terminal without a reader or to extractinformation from an SE in a cellular network adapter without a reader.Such embodiments add value in a mobile commerce or e-commerceenvironment by enabling more secure transactions over a voice network oran internet.

To prevent fraud, electronic transaction systems typically attempt toverify one or more of the following characteristics of a requestor:

-   -   1) Something the requestor knows (a password, answer to a        question, etc.)    -   2) Something the requestor has (a physical token, such may be        confirmed by embodiments herein)    -   3) Something the requestor is (such as a physical trait        established by a fingerprint or other biometric identifier)

“2-factor authentication” is defined as an authentication where therequestor (the entity to be authenticated) successfully provides two ofthe above three different types of verifications. If two of theseverifications have been provided the authentication is considered“strong.” One important advantage of many embodiments described hereinis the ability to confirm that a card is present and authentic. This byitself provides a basis for 2-factor authentication over a public orprivate network using currently ubiquitous access hardware such as acomputer terminal or a cellular network device.

Described herein are configurations of a “Reader On Card” (ROC) or“self-swiping” card, or “self-authorizing” card. The terms “ROC,”“self-swiping” and “self-authorizing” are synonymous and refer aconfiguration wherein the card device or cellular network adaptercontains both an SE and SE reader functionality. Configurations for adynamic or encrypted PAN (Personal Account Number) are also described.This refers to configurations where the “Reader On Card” furtherencrypts the track data in order to securely transport the data packetover a public network. Neither of these concepts is limited to oneparticular form factor or embodiment. Some examples of devices that mayemploy these elements include a USB device or a token or a mobile phonethat is enabled with contactless (13.56 MHz radio frequency) or NFC(Near Field Communication) RFID technology.

An SE typically contains a microprocessor, random access memory (RAM)that stores a data file, read-only memory (ROM), flash memory (EEPROM),encryption engine(s), and one or more methods of interfacing the SE.Executable applications such as the MasterCard, PayPass, VISA,Contactless, and AMEX Express Pay may be compiled and placed on an SE.Personalization information that is unique to the specific card holderis generally also placed on an SE. The applications for an SE aretypically specified by application providers such as MasterCard, VISA,or AMEX among others. The applications may be created using any numberof software development tools and then compiled to run on any number ofSE architectures.

The applications running on the SE are typically provisioned with cardholder specific information prior to being delivered to the card holder.The provisioning entities such as First Data Corp. must follow strictguidelines set forth by card associations such as VISA, MasterCard,AMEX, and others that keep the provisioning process secure and ensurethat customer data is protected inside the SE and that only the cardissuing banks or their agents are able to verify the information that isextracted from the SE. It is important that this process is notdisrupted and abided by while including the advantages of the presentinvention.

In order to extract information from the application(s) on an SE, aninterrogator, also referred to as a “reader”, is required to interactelectrically with an SE. The interrogator software may be provided inmany different forms such as a software module or a pre-programmedmicrochip. The hardware that the interrogator runs on may also come indifferent forms such as an ARM processor, or a small M8 processor. Thehardware that encompasses a SE and or an interrogator may be referred toas a chip or die. A die is the raw silicon that is packaged during thechip manufacturing process.

The applications on an SE are accessed by a reader with specificquery/response calls defined by the application provider as mentionedabove. These applications are generally designed to protect the data ona SE via encryption engines in the SE. The protocols used by a reader topass data to and from a SE are typically defined in the ISO 7816 or ISO14443 specifications. These protocols are referred to as query/responseprotocols. An interrogator sends a query and a SE sends a response.

In many embodiments the physical interface between a reader and an SEconforms to standards defined in the ISO 7816 and ISO 14443specifications. The ISO 7816 specification defines a “Contact” interfaceto a SE in which the SE is powered by DC voltage and ground electricalconnections from an interrogator. The data transfer during theinterrogation is managed by an interrogator providing a clock signalconnection and data line connection to an SE. The ISO 14433specification defines a “Contactless” interface to an SE in which the SEis powered by an inductive field produced by an interrogator during theinterrogation. The data transfer during the interrogation is managedover a 13.56 MHz carrier signal provided by an interrogator. Thephysical interface that the interrogator uses to connect to the SE mayalso be provided in different forms such as UART, or an NXP proprietaryS2C interface. It is also possible that the interrogator shares the samesilicon chip as the SE and the interface between them is provided byinternal memory or physical traces in the silicon.

The “Universal Serial Bus” USB interface is a standard interface tolaptop computers and personal computers or other form of computerterminal as a means of expanding the capabilities of the computerterminal or transferring information between the computer terminal andanother device. More information about the USB interface may be obtainedat www.usb.org.

The “Human Interface Device” HID interface is a class of USB interfacewhich is a universal standard for a USB host to connect to USB clientdevice. Within the HID class, there are several defined types ofdevices, including a “keyboard” type. By the USB device interfacing theUSB host with the “keyboard” type of HID class interface, the standardsrequire that the USB host recognize the device as a standard device(e.g., a keyboard) and accept input as such without requiring that thecomputer have any special drivers or operating system updates installed.By configuring a card device as an HID keyboard the card device emulatesa keyboard attached to the computer terminal. The computer terminal willrecognize and accept the card device as a keyboard input device. This isa very useful feature in many applications for enabling a more userfriendly “self-swiping” functionality in the card device.

Included in most embodiments is a “communications controller.” Thecommunications controller provides the interface for data exchangebetween the reader and a communications connector (in the case of a carddevice) or the interface for data exchange between the interrogator anda cellular network application interface (in the case of a cellularnetwork adapter). The communications connector may be provided indifferent forms such as USB, USB connection with HID class keyboard typeor USB connection with mass storage class, among many others. Theinterface may be established using other hardware interface standards aswell such as SDIO, mini-SD. In many card device embodiments thecommunications connector is an integral part of the card device, meaningthat the communications connector is formed on an edge portion of thecard. The cellular network application interface may, for example, beprovided as a baseband input/output port for a web browser running onthe cellular network device. The physical connection may be provided bya communication bus or by micro-circuitry in common processor and memoryareas in the baseband portion of the cellular network device.

In either card device embodiments or in cellular network adapterembodiments, the communications controller may be physicallyincorporated into the reader or may be physically incorporated into thesecure element or the communications controller may be a physicallyseparate electronic element. In some embodiments the capabilitiesdefined herein for the communications controller may physically beperformed in the chip that is primarily the SE and/or the interrogator,or the capabilities of the interrogator may physically be performed inthe chip that is primarily the SE and/or the communications controller.,or the capabilities of the SE may be physically performed in the chipthat is primarily the communications controller and/or the interrogator,or the capabilities of the interrogator and the SE and thecommunications controller may all be performed in a single chip. In anycase, the capabilities of the communications controller, the SE and theinterrogator are still considered to be performed by the “communicationscontroller,” the “SE” and the “interrogator” respectfully. Furthermore,in some embodiments the PDA or phone processor may be connected directlyto the SE. In such embodiments the phone processor interrogates the SEto achieve valid transaction data from the SE. The PDA or phoneprocessor may deliver this data to a form field or directly over thecellular network. In such embodiments the communications controller andthe interrogator of the SE are now a portion of the PDA or phoneprocessor itself instead of either of communications controller or theinterrogator being a separate hardware chip.

In some embodiments of a self-swiping “Reader On Card” (ROC) device theinterrogator and SE are integrated together on the same medium, deviceor circuit. It is important to note that in contactless implementationsthe interrogator portion of the ROC device may not be able to functionfrom power harvested from the contactless inductive antenna, andtherefore may require power from an external source, such as thecommunication connector to the computer terminal (in the case of a carddevice) or the cellular network device battery (in the case of acellular network adapter).

The data that are automatically delivered to the host device mayrepresent bank account information in the form of “Track 1” and/or“Track 2” data. Track 1 and Track 2 data are commonly-usedrepresentations of bank account information that is specific to a cardholder. These data generally have a very specific industry standardformat in order to be properly processed through transaction processingsystems. The Track 1 data format was developed by International AirTransportation Association (IATA). The Track 2 data format was developedby the American Banker Association (ABA). In some embodiments the Track1 data that are generated as file information from the SE data file andconverted into transaction information by the communication controllerand transmitted to the host device may comprise only a portion of theTrack 1 data content specified in a standard published by the IATA. Insome embodiments the transaction information may be the entire Track 1data content specified in an IATA standard. In some embodiments theTrack 2 data that are generated as file information from the SE datafile and converted into transaction information by the communicationcontroller and transmitted to the host device may comprise only aportion of the Track 2 data content specified in a standard published bythe ABA. In some embodiments the transaction information may be theentire Track 2 data content specified in an ABA standard. However, it isimportant to note that in some embodiments the transaction datadelivered to the host device may not be standard Track 1 or Track 2data. It is possible that this data may be in another standard orproprietary format. In any case, the transaction data may or may not bean encrypted cipher text in whole or part upon delivery to the hostdevice.

Typically a card device transaction authorization process begins when auser is instructed by a web browser-based application program on acomputer terminal to insert a self-authorizing smartcard into a USB porton a computer terminal. When the smartcard is inserted, if theself-authorizing smart card is a USB HID keyboard class card device, thesmartcard typically self-initializes with the operating system of the PCand begins to automatically input the relative card data into theappropriate field in the browser form. Many embodiments automate theinput of card information such as PAN, expiration date, and securitycode. The USB HID keyboard class card device may use access keys or “hotkeys” to navigate the form that has the current focus for input in thecomputing device. The card device may also automatically remove anyinformation that may have been inadvertently typed prior to card deviceinsertion. The card device may also automatically “submit” the onlineform using access keys or “hot keys”.

An example where the HID keyboard device of the card automaticallyinputs a sequence of key presses of the device using “hot keys” is asfollows.

-   -   a. [alt]+‘,’ (This makes the cursor take focus on form element        that has a designated access key of ‘,’—the comma key)    -   b. [ctrl]+‘a’ (This makes the cursor select all the text that is        existing in the current field of focus)    -   c. [Backspace] (This makes the cursor erase all the currently        selected text)    -   d. [alt]+‘.’ (This makes the cursor take focus on the form        element that has a designed access key of ‘.’—the period key . .        . this could be set to a “submit” button for example)

A benefit of many embodiments is delivery of the information on the SEto the form that has the current focus for input in the host device. Aself-authorizing smart token or a self-authorizing cellular networkadapter the may deliver this information in a manner of emulatingkeystrokes from a keyboard device to the host device. For securityreasons the application program that has the current focus on the hostdevice (and is collecting this input) may take precaution inside itsprogramming logic to require that the keystrokes being input into aparticular form field are keystrokes and not simply a “paste” keystrokefrom an electronic “clipboard.” Alternately, the application program mayrequire that the keystrokes being input into the form field are fastkeystrokes resembling the pattern that only an automated keystrokeemulation input device could provide, and not a slower pattern of inputthat would resemble a manual input of keystrokes. Knowing theserequirements, the communications controller element of the card deviceor the cellular network adapter may be programmed to provide thetransaction information to the host device in a prescribed cadence foran application running on the host device.

For security reasons the form that has the current focus on the hostdevice and is collecting this input may take precaution inside theprogramming logic that various pattern of “hot key” presses ([alt]+‘somekey’) may be used to identify the input device as a secure input device.It is important to note the “hot key” keystrokes cannot be duplicatedwith the traditional “copy”, “cut”, or “paste” to the clipboard thatsome operating environments provide. However, such hot key keystrokesmay be provided by various embodiments of communication controllers inself-authorizing devices defined herein.

Many embodiments deliver Track 1 and/or Track 2 data to a merchant fromthe SE of a payment card using the USB interface of a remote customer'sPC in a simple, customer friendly manner. The consumer typically onlyhas to insert the card device into a USB port on his/her computingdevice and the keystroke data will automatically input into the formthat has the current focus on the computing device via keyboardemulation from the card device.

Many embodiments deliver Track 1 and/or Track 2 data that contain adynamic card verification number from the SE of a payment card device,using the USB interface on a PC of a remote customer.

Many embodiments deliver Track 1 and/or Track 2 data that contain anincrementing transaction counter from the SE of a payment card device,using the USB interface on a PC of a remote customer.

Many embodiments use a “unique number” that is stored in the SE anddelivered from the card device as further access control security thatmust be provided to in order to protected content such as recordedmusic, recorded video, live media, photos, documents and other similarmedia. An example of this is that the data file of sensitive or licensedcontent may be encrypted with a key or a diversified key based on thekey within the SE. This would allow only the card holder of the SE tosuccessfully “unlock” and view or listen to the protected content.

Many embodiments use a transaction counter that is stored and updated inthe SE to uniquely identify a card holder as well as uniquely identifyeach given transaction or “swipe” from the card device. Remotetransaction approval software may check that the Track 1 and Track 2data from an SE is what is expected for the current transaction, and mayupdate the transaction counter for the next transaction.

In many embodiments the card device is configured to resemble thephysical form factor of typical payment cards as closely as possiblewith the exception of adding a region of the card that is meant to beinserted into the USB port of a computing device. This facilitatescarrying the card device in an ordinary wallet or purse.

In many embodiments the smart token is configured to resemble thephysical form factor of a “fob” that may be placed on a consumer keyring.

In many embodiments the card device is configured to limit the height ofthe USB connector so that the device is thin enough to still be carriedin an ordinary wallet or purse.

In many embodiments the self-authorizing smart token or theself-authorizing cellular network adapter is designed to minimize partcount and assembly costs so that it can be manufactured at a very lowprice for high volume, low cost uses.

Referring now to FIG. 1, the face and back of the self-swiping cardmedium 10 are shown. The dimensions of this embodiment are roughly 2⅛×3⅛inches, with a preferred maximum thickness of 0.09 in. The nominalthickness of the card is a maximum of 1/32 in. Looking at the left sideof the figure, there is a diagonal protrusion 12 that contains theconnector 14 for a USB connection of a mating PC. The four contactsvisible in the figure are the power, ground, D+, and D− signals that aredefined in the USB specification at www.usb.org. The diagonal of the USBconnector protrusion 12 is approximately 45 degrees and allows theprotrusion approximately ⅝ in. clearance for insertion into a USBconnector on a PC. The boundary of the card has been adjusted from itstypical rectangular shape to account for this connection area. Thediagonal protrusion has a clearance gap 16 between itself and the lowerboundary of the card as seen in the figure. This gap 16 is for thepurpose of allowing clearance of the “thicker” USB connection protrusioninto some forms of “insertion” type magnetic stripe card readers. Theface of the card also shows the PAN (portrayed as 0000 0000 0000 0000),expiration date, and card holder name in similar location to a typicalrectangular banking card. The back of the card includes a magneticstripe 18 that is disposed in a location similar to that of a typicalrectangular banking card.

Referring to FIG. 2, the close view of the USB connection protrusion ofthe self-swiping card medium as shown. Note the change in this thicknessof the card from region 30, where the card is approximately 1/32 inchthick to zone 32 where the maximum thickness of the protrusion isapproximately 0.09 in. where the USB contracts 34 are located. Theprotrusion of the male USB connection is approximately 15/32 in. wide inorder to fit into the standard USB female connection on a PC as definedat www.usb.org. Approximately 3/16 in. in back of the leading edge ofthe protrusion there is a notch 36 that changes the thickness of theprotrusion. This thickness change is for accommodating the “snap fit” ofthe USB female connector on the PC as defined at www.usb.org. Theclearance between the leading edge of the protrusion and the bulk of thecard medium is approximately ⅝ in. The style of this particular type ofUSB connection is not a standard mail USB connection. It has beenaltered to be much thinner than the typical male connection. As aresult, it is susceptible to “upside down” insertion into the female USBconnection.

Referring to FIG. 3, the profile of a self-swiping card 50 with insidecomponents exposed is shown. An antenna 52 is a printed or wire woundantenna that creates an inductive coil that provides power and transmitsdata to and from a secure element 54. The number of turns in the antenna52 is dependant on the properties of the SE as well as the size ofsurface area the perimeter of the antenna covers. The antenna 52 isembedded inside the card medium and may or may not be congruent with thecard medium perimeter. In some embodiments it may be desirable to shrinkthe area of the antenna 52 for manufacturing reasons such as cardembossing. The secure element 54 shown in FIG. 3 is a microchip die thatis wire bound to the module face plate through manufacturing methods.The secure element microchip die is typically then coated with epoxy forprotection. In the embodiment of FIG. 3 the secure element 54 is a dualinterface device that is accessible through the contactless antennainterface or through the contact 7816 style interface. When not pluggedinto the USB connection on a PC, the antenna serves as the sole powersupply, data transmitter, and data receiver for the SE 54. When pluggedinto the USB connection on a PC, the antenna 52 is not intended to beused as a power supply or to transmit or receive data. Instead acombined interrogator/communications controller reads information fromthe SE 54 and transmits information to the PC through a USB connector onthe protrusion of self-swiping card 50.

The protocols that define the communication to the SE are defined in ISO14443 (contactless) and ISO 7816 (contact). The commands to communicateto the applications that are running on the SE are typically designed tointerrogate the secure element and execute file system functionsaccording to ISO 7816-4 in order to generate file information from SEdata file. However, in some embodiments the commands to communicate tothe applications that are running on the SE are provide by theapplication providers. In any case, the commands are generally the sameregardless of the interface method (contact or contactless).

The SE is generally a secure microchip that has built in encryptionengines, RAM, micro-processor, EEPROM, and communication interfaces. Theinterrogator and the communication controller (USB interface) chip shownin FIG. 3 is a chip that contains a microprocessor, RAM, EEPROM, andbuilt in USB interface engine. The chip is programmed to describe itselfto the host PC as a HID class “keyboard” device upon connection to thePC. The chip then communicates to the SE via ISO 7816 (contact)interface protocols to acquire and build Track 1 and Track 2 data. Aftertrack data are acquired from a successful “read” of the SE, the data isthen delivered to the PC's USB bus through the communications connectorprotrusion shown in the FIG. 3. It is important to note that it ispossible for both the SE and the interrogator/USB interface chip die tobe mounted and wire bound together on the same module medium. It is alsoimportant to note that these two chips could also be contained in onepiece of silicon sharing the same RAM and/or EEPROM memory space.

FIG. 4 illustrates a circuit board schematic 60 according to oneembodiment. This shows a more detailed layout of the componentsdescribed in FIG. 3 as well as the supporting components of typicalembodiments. In this particular embodiment, the interrogator/USB bridgechip/die is a chip made by cypress semiconductor with a part number ofCY7C3. The SE used in this particular embodiment is a chip/die with astandard ISO 7816 contact type interface in combination with a standardISO 14443 contactless interface.

FIG. 5 illustrates a flow diagram that describes one method embodiment.After the card device is plugged into the USB connector on the customercomputing device, the card device powers up and begins to interrogatethe SE on the card device. The interaction and data exchange between theinterrogator chip and the on the SE could look something like thediagram in FIG. 5.1. In preferred embodiments the interrogation processconforms to application level protocols (APIs) established by ISO7816-4. ISO 7816-4 defines two such application-level protocols:

-   -   (a) File system API providing a set of functions to manipulate        files (e.g. read, write, select etc.)    -   (b) Security service API allowing the smart card and the reader        to mutually authenticate themselves and also to encrypt data to        be exchanged between the card and the reader.

In preferred embodiments the interrogation process conforms to protocolmessage structures also defined in 7816-4 to support the APIs. Thismessage structure consists of application protocol data units (APDUs)which are exchanged between the reader application and the smart cardapplication by the link level protocol. There are two types of messagesused to support the ISO 7816-4 application protocols: the commandApplication Protocol Data Units APDU (sent from the reader to the card)and the response APDU (sent from the card to the reader).

After the interrogator has received the all the data from theinterrogation of the banking application on the SE, the interrogator canthen build the data string that is to be sent to the computing device askeystrokes. It is important to know that the SE can run multipleapplications from different application providers. It is possible, andis one embodiment of this invention, for the interrogator to deliver theinformation that was acquired during interrogation of the bankingapplication on the SE to a second application that resides on the sameSE so that the second application can process, build, and possiblyencrypt the data that will be delivered to the computing device askeystrokes.

An example of this embodiment that contains the interrogation of twoapplications on the SE may look something like the diagram in FIG. 5.2.The dotted lines in the figure represent the times during the entireinterrogation of the SE that the interrogator selects differentapplications to use. The interrogator or the interrogator application onthe SE may or may not encrypt the final Track 1 and/or Track 2 data.

FIG. 5.3 shows one embodiment of a method of encrypting this data. Afterthe interrogator has acquired or built the data to be sent to thecomputing device as keystrokes, the USB interface enumeration begins.During the enumeration process, the card device, which is the clientdevice, exchanges information with the USB host device. The informationexchange is defined in the USB specifications and can be obtained atwww.usb.org. As part of the exchange, the card device will send“descriptors” that tell the host device about the drivers that arerequired to run the client card device. The descriptors that the carddevice sends to the host include a HID (Human Interface Device)descriptor. The card device sends another descriptor that furtherdefines the type of HID device to be a “keyboard” type of device. TheUSB host will now recognize the card device as a keyboard and expectthat the card device will deliver “key codes” that represent keystrokesas input data. After enumeration has occurred and the host USB devicerecognizes the card device as a keyboard, the card device begins todeliver data to the current form that has the focus on the computingdevice. The data that are delivered may consist of:

-   -   a. Identification of the entity to which the data must be passed        to for further processing.    -   b. Identification number of the particular card device that is        delivering the data.    -   c. Identification number of the cryptographic key to be used for        decrypting the data that is delivered from the card device.

The application, such as an internet browser, that is running on thecomputing device that has collected this information is then responsiblefor passing the information to the entity identified by the data abovefor processing. One embodiment of this invention involves passing thisinformation in an online setting by one internet server passing thisinformation string to another internet server. In this embodiment, theentity that controls the internet server that receives this informationcan then process the information along with the identity of the owner ofthe requesting internet server as they see fit. The entity that receivedthe data can then return resultant data back to the requesting party.Also, in this embodiment, the information that is passed back to therequesting party is Track 1 and/or Track 2 data that is used to processtypical card payment transactions by merchants.

Referring to FIG. 6 the internet browser form that receives theinformation from the card device as shown. This form represents oneexample of how a card device may be used. In this example an applicationrunning on a PC includes one specific field 100 on a form that isdesignated as the field that the card device will automatically populatewhen the card device is plugged into the PC that is displaying thisform. In this example, the application has been programmed so that theform field 100 can be addressed using an access key or “hotkey” of ‘,’(the comma key). That is, when the card device issues this “hot key”keystroke (by use of keyboard emulation), the cursor will automaticallymove its focus to the field 100. The HTML (hypertext markup language)code that is used to create the self populating field may have thissyntax:

<input type=“text” name=“data” size=“” access key=“,”/>

The card device then populates the form field 100 with data. Then theauto-populating field 100 may be further checked by the applicationprogram for the authenticity of the keystrokes by the internet browserusing “Java-Script” code that may be embedded into the HTML code. Also,the internet browser may check that each key was actually typed into thefield by keystrokes rather than the use of “copy”, “cut”, and “paste”commands that may be provided some operating environments. The internetbrowser may also check that each keystroke was typed very fastresembling an automated input rather than a slower manner that wouldresemble manual input. The internet browser may check other aspects ofthe input data for its validity as it sees fit.

Referring to FIG. 7, an internet browser screen displays decrypted data110 that may be provided to a merchant transaction authorization system.The track information shown here is acquired using a Reader On Card(ROC) system. After the card reader extracts information from the SE andbuilds the track data containing the DVCC from the SE on the card, thetrack data are then delivered to the appropriate field in thetransaction requester's browser as encrypted data via a USB HID keyboardinterface. The information that is auto-populated on the requester'sscreen is not the Track data that is depicted in FIG. 7 because the ROCsystem encrypts the track data on the card device before the field onthe requestor's browser is populated and the encrypted data aretransmitted. The data on FIG. 7 is a decryption of the data that appearson the requester's screen. If the process is repeated by the requesterthe DVCC data and the transaction counter will change, in accordancewith specifications for secure transaction encryption. In a typicalapplication a merchant that is processing the information would notexpose the clear text track information portrayed on the browser screenof FIG. 7. This figure is merely showing it as an example of thedecrypted data. It should also be noted that in many embodiments the SEon the requester's card device may be used to make contactlesstransactions at in-store POS terminals by holding the card device up toa contactless reader.

Referring to FIG. 8, the face of one embodiment of a self-swiping card120 is depicted. The placement of the protrusion that exposes the USBconnection, relative to the card boundary 122, is important. The USBconnector 124 may be manufactured in a similar fashion to a typical ISO7816 smart card module. The typical ISO 7816 module is then seated intothe card medium during an assembly process. The exact placement of themodule relative to the card boundary is defined in the ISO 7816specification and many of the assembly machines used to place thismodule inside the card medium is set to place the module in a specificlocation as shown in the figure.

Referring to FIG. 9, one embodiment of an alternate form-factorself-swiping card 140 is shown. This embodiment includes a USB connector142 but has a form factor that lends itself to placing the card deviceon a key ring through a hole 144. The purpose of this figure is toillustrate some of the wide variations that can encompass variouspotential embodiments.

Referring to FIG. 10, components of a smartcard module 150 are depicted.On the left is the connector plate (module top) and on the right is themodule bottom of the smartcard module 150. Looking at the right side ofthe figure, the bottom of the module exposes how the die from both theSE 160 and the interrogator 156 may be mounted. Also shown in the rightportion of this figure, are the mounting pads 158 that may be connectedto the inductive coil antenna for the contactless interface of the SE.The inductive coil antenna is typically assembled into the card mediumprior to placement of the smart card module. The mounting pads aredesigned to make contact with the exposed ends of the inductive coilantenna. Looking at the left side of the figure, the connector plate iscarved or scored in such a way that the connection pads 154 alignthemselves with the standard female USB connections of DC voltage,ground, D+, and D− that are defined in the USB specification atwww.usb.org.

Two embodiments of a self-swiping card medium are shown in FIGS. 11A and11B. FIG. 11A depicts a standard “miniSD” 180 that is a common formfactors for expansion memory or IO functionality. The miniSD 180 has awidth 184 that is approximately 20 mm and a height 184 that isapproximately 21.5 mm. FIG. 11B depicts a standard secured device (“SD”)190. The standard SD has a width 192 that is approximately 24 mm and aheight 194 that is approximately 32 mm. These form factors 180 and 182are fairly ubiquitous in mobile phones and personal digital assistants(PDAs) and therefore are convenient for use in various embodiments of acellular network adapter. The SE and other electronics to interrogatethe SE may be contained within these form factors. Additional featuresmay be added such as additional expansion memory for the mobile deviceor PDA to access. Further detailed specifications for the SD 190 and theminiSD 180 form factor may be obtained at www.sdcard.org.

FIG. 12 illustrates a flow diagram that describes one method and useembodiment. After the card device is plugged into the USB connector onthe customer computing device, the card device powers up and begins tointerrogate the SE on the card device. The interaction and data exchangebetween the interrogator chip and the on the SE could look somethinglike the diagram in FIG. 5.1. After the interrogator has received theall the data from the interrogation of the banking application on theSE, the interrogator can then build the data string that is to be sentto the computing device as keystrokes. It is important to know that theSE can run multiple applications from different application providers.In some embodiments the interrogator delivers the information that wasacquired during interrogation of the banking application on the SE to asecond application that resides on the same SE so that the secondapplication can process, build, and possibly encrypt the data that willbe delivered to the computing device as keystrokes.

An example of an embodiment that contains the interrogation of twoapplications on the SE typically looks something like the diagram inFIG. 5.2. The dotted lines in the figure represent the times during theentire interrogation of the SE that the interrogator selects differentapplications to use. The interrogator or the interrogator application onthe SE may or may not encrypt the final Track 1 and/or Track 2 data.Specifically, in the embodiment reflected in FIG. 12 the PAN or PersonalAccount Number is encrypted within the final Track 1 and/or Track 2data, or possibly by itself only. The encryption is handled in such away as to not disturb the bank routing code within the PAN. This istypically the first 6 digits of the PAN. The final digit of the PAN isalso adjusted as to equal the proper check digit for the new PAN. Oncethe new PAN is created from encrypting the original PAN, it issubstituted in the place of the original PAN. Using this method, themerchant is able to receive the PAN and verify that it is a valid creditcard number by checking the digits and calculating the proper checkdigit. After the PAN is submitted to the merchant for processing via HIDkeyboard buffer which prints the PAN and possibly other data into a “webform,” the information is submitted by the user for processing. Themerchant would be able to authorize the transaction as it would anyother credit card transaction over the internet. When the encrypted PANis submitted to the processor for authorization, the processor is ableto send the encrypted PAN to a decryption device that will properlydecrypt the PAN and build the original PAN to check for authorization.The advantage of using a method like this is that valid Personal AccountNumbers are never transmitted from the user's computer over theinternet.

To add further protection to the encrypted PAN, there is a transactioncounter that can be factored into the encryption algorithm. This allowsfor a unique card number for each transaction that is processed. Theencryption algorithm, encryption key, and transaction counter may becontained within the SE of the card. The encryption of the PAN may takeplace with every transaction and to take place within the SE. This typeof encryption of the PAN may used with several embodiments of thepresent invention including mobile phones containing a SE. In the caseof the mobile phone, the interrogation of the secure element is verysimilar to the interrogation depicted in FIG. 5.2. The mobile phone maynot deliver the final data to a “web form”, however, by auto populatinga field, but instead it may receive the encrypted PAN and other datawithin its own memory structure and then pass the data to the merchantfor processing either via internet or its own phone connection. In anycase, this method of PAN encryption helps to protect the original PANdata that is needed to authorize a transaction. Because the PAN data isencrypted on the card itself, it may be considered safe to transmit overa network in clear text to the decryption device.

FIG. 13 presents a representation of a Personal Account Number or PAN200 that is found on the face of a credit card and within the Track 1and Track 2 data that is stored on the magnetic stripe or SE of a creditcard. The first set of digits 202, usually ranging from the first 3 tothe first 6 digits, is referred to as the Bank Code. This code isdesignated as a routing number for the many card association networksthat describes which bank or “issuer” the PAN belongs to. The second setof digits 204 shown in FIG. 13 indicates the personal account number ofthe card holder at the issuer. The last digit 206 of the PAN is usuallyconsidered a “check byte” that is used to calculate if the complete PANis indeed a valid PAN number. The algorithm normally used for the “checkbyte” is called the Luhn algorithm. The algorithm uses the digits in thePAN itself to make the proper calculation of the check byte. For thisreason, if any digit in the PAN is changed, it is likely that the checkbyte will also need to be adjusted in order to make the new PANconsidered valid. When encrypting the PAN, it is important not to changethe bank code. The bank code may remain the original bank code in orderfor the encrypted PAN data to be routed to the appropriate bank and thento the decryption device that will replace the encrypted PAN digits withthe original PAN digits.

In FIG. 13.1, and FIG. 13.2, one embodiment of an encryption algorithmis shown. This embodiment used DES in OFB mode as described in FIPS 81as defined by NIST. A known initialization vector is XOR with atransaction counter that is maintained by the reader-on-card. Everytransaction that is committed to, the counter increases. This willeffectively change the initialization vector for encrypting the PANdigits. In a separate embodiment, it is also possible to incorporate atimestamp into the randomization processes of the initialization vector.This may not be possible in embodiments that do not have access to anaccurate clock. After the initialization vector is XORed with thetransaction counter, or other information, DES encryption is performedon the 64 bit, value using the DES key that is has been previouslyloaded into the interrogator application that is stored on the SE. Thisproduces a 64 bit output value.

FIG. 13.2 shows the 64 bit output value from FIG. 13.1. The originalaccount number from the PAN is also shown. The digits that will bechanged within this account number are typically the middle 5 digits‘6784’. The leading three digits ‘0’ are generally reserved asplaceholders for passing the transaction counter to the decryptiondevice. The final two digits ‘80’ are generally used to mark a DES keyID for the decryption device. The DES key ID may or may not be includedis some embodiments. The purpose is to allow many different DES keys tobe used by many different interrogators. Further on this subject, it ispossible to create greater randomization of DES key by including adiversification process of the DES key in the interrogator application.A diversification process takes a master key and applies an algorithm tothe key based on known data to produce a further randomized key to beused in the actual transaction. The two-digit key ID may actually beused to diversify a master DES key instead of identify a separate key.

The middle 4 digits to be encrypted may be represented in 14 bits. The14 bits to be encrypted of the original account number are also shown atthe bottom of FIG. 13.2. According to FIPS 81, using DES in OFB mode,the number of bits to encrypt can range from one to sixty-four duringeach iteration of the algorithm.

In this particular embodiment one iteration is shown, resulting infourteen bits of encrypted cipher text. In order achieve the finalcipher text; the first fourteen bits of the DES encrypted output textare XORed with the fourteen account bits that are to be encrypted. Theresultant output is the fourteen bit cipher text to be placed back intothe PAN, creating an encrypted PAN. FIG. 13.3 shows the conversion ofthe fourteen bit output from FIG. 13.2 into a four digit decimal. Thefour digit number is then placed into the issuer account number alongwith the transaction counter as shown in FIG. 13.3.

FIG. 13.4 shows the total encrypted PAN 250 with the bank code 252, theaccount number 254 and the updated check digit 256 that reflects the newPAN digits. Now, it is possible for this number to be processed in theexact same manner as a legitimate card PAN. The decryption device mustbe used to replace the encrypted PAN with the original PAN, but it isimportant to note that all the information for how to do so, includingthe transaction counter and DES key ID are included in the encryptedPAN.

The number of digits used for the DES key ID, transaction counter, andencrypted digits may vary depending on implementation of this method andthe particular embodiment. It is also possible to share a single digitto represent parts of two different data elements. One example of thiswould be to divide a digit by 2 and discard the remainder to represent0-4 for one data element (transaction counter, DES key ID, or encrypteddigits), and then to divide the same digit by 2 and only use theremainder to represent 0-1 for separate data element (transactioncounter, DES key ID, or encrypted digits).

Referring to FIG. 15, the internet browser form that receives theinformation from the card device as shown. This form is shown after thefield 300 has been self-populated. The content in the form that is shownis an example of an encrypted PAN which is digits in this case and has abank routing code of ‘541312’. The transaction counter is populatedbackwards over the next 3 digits ‘101’. The third digit, in thisexample, is used to share with the encrypted digits data element asdescribed in the previous paragraph. So, the transaction counter isactually showing ‘001’ when reversed. Including the shared digit, thenext 5 digits represent the encrypted digits of the account number‘14194’. The following two digits, ‘80’, represent the DES key ID. Andthe final digit of ‘1’ represents the check byte.

Looking at FIG. 15.1, the same “web form” as shown in FIG. 15 is shownwith a field 302 auto populated with a second transaction from the samecard device. When comparing the encrypted PAN's from FIG. 15 and FIG.15.1, the differences are seen here:

-   -   1^(st) Transaction—FIG. 15: 5413 1210 1419 4801 (encrypted PAN)    -   2^(nd) Transaction—FIG. 15.1: 5413 1220 1176 280 (encrypted PAN)        When these transactions are received by the decryption device        the original PAN may be decrypted and created. In this        particular example shown in these figures, the original or valid        PAN is:    -   Original PAN: 5413 1200 0763 2801 (valid PAN)

FIG. 14 illustrates a flow diagram that describes one method embodiment.This particular embodiment is generally not appropriate for use with theHID keyboard emulation class of a USB device. This embodiment shows a2-way form of communication from the base band device or host PC to thecard device. The HID keyboard emulation class of a USB device istypically a 1-way device upon which the HID keyboard USB devicecommunicates to the host PC via an “in” endpoint only. This allows datato move from the keyboard emulation device to the PC only. In such acase the interrogation most likely starts at the time the USB device isplugged into the computer and cannot be initialized by the PC.

The 2-way device as shown in FIG. 14, offers some added features to thesystem. In a case like this, the interrogation of the SE may becontrolled by the base band device or by the host PC. Data such as anunpredictable number (UN), a timestamp, or some other type ofdeterministic data may be used during the interrogation of the SE, ormay be sent to the card device to initiate an interrogation. Anunpredictable number refers a number that may be used in algorithms ofcertain financial transaction authorization systems, such as VISA® orMASTERCARD®, in the encryption phase of a dynamic card verification code(DCVC). A DCVC is a 3 digit encrypted number that changes for eachtransaction (the dynamic aspect of the track data). The algorithm tocreate a DCVC typically uses a UN, a transaction counter, and DES key toderive a DCVC for each transaction. In some embodiments the financialtransaction authorization system instructs a reader to create anunpredictable number. In some embodiments the communications controllermay be configured to create a random UN and send it to the secureelement during a transaction. The UN may be constructed as a hash of atimestamp, for example, and such a UN would ensure the authorizationsystem that the SE made and returned its encrypted DCVC and that it wasconstructed at a certain (recent) time. This also adds another layer ofsecurity by establishing a basis for a precise expiration time for aparticular transaction.

After the interrogation is complete, the resultant data string may besent back to the base band device or host PC. There are many ways thissystem can be implemented. One example of an implementation would beusing a generic HID class that allows both an “in” endpoint and an “out”endpoint to the USB card device. Both the “in” and “out” endpoints of aUSB device are described by documentation that may be obtained at thewww.usb.org website. The HID class driver is packaged and available onmost host PC's. In order to use this HID class driver on a host PC, aclient application must be resident and running on the host PC thatidentifies the proper HID device when it is connected to the host PC.The client application that is using the HID class driver may then issuecommand packets to the USB card device using the HID class interface andreceive response packets from the USB card device using the HID classinterface. Although using the HID class interface is not quite asubiquitous to the system as using the HID keyboard class interface, itis still more ubiquitous then communicating to the USB device using acustom driver implantation. The HID class interface is possible toimplement in PC side applications without creating a hardware driver 5that runs on the host PC. The HID class interface can be created andused as a plug-in to internet web browsers and other PC applications.The HID class interface can also be built into simple executableprograms that are allowed to communicate directly to a USB card.

In a similar embodiment it is possible to create a dual-purpose USBdevice that has both a HID class driver that allows an “out” endpoint tocommunicate to the USB card device from the host PC, and also uses theHID keyboard class interface with an “in” endpoint to send data back tothe host PC via keyboard emulation. Another implementation of thissystem could be entirely contained inside a mobile phone. A 2-way datachannel is used to initiate an interrogation with a secure element aswell as receive the resultant data string after the interrogation iscompleted. It is important to note that there is a dashed line thatencompasses a rectangle on FIG. 14 that contains both the “initiator”and the “interrogator” entities. These two entities may be handled andrunning within the same base band processor in the mobile phone. In thiscase they may exchange information within libraries or memory spaceonly. The mobile phone may receive the resultant data via a keyboardbuffer that can then auto-populate a form field, for example, in amobile web browser. In any case, the 2-way data channel can be used togive more control as well as possibly more security to the system. Bypassing the unpredictable number, that is used in the dynamic CardValidation Code (CVC) generation within the SE, timestamp, or some othertype of deterministic information, the baseband portion of the mobilephone or the host PC may validate and timestamp any transaction that itrequests by linking a timestamp to a particular unpredictable number.

Also, the 2-way data channel represented in FIG. 14 allows for theentire transaction to be triggered by the base band device or host PC.The act of sending data to the card device can signal a start to theinterrogation process.

Referring to FIG. 16, a diagram of a mobile phone with contactless orNFC functionality is displayed. One purpose of a mobile phone or likedevice with NFC technology is to enable the mobile phone itself to actas a payment card in order to make payments at a contactless terminalthat may be located at a retailer location. In this embodiment the SE isembedded in a Secure IC within the phone. The SE on the phone maycontain multiple bank accounts and may be controlled by the userinterface of the phone. The diagram depicts the phone itself (basebandportion), the cellular network adapter 320 that includes a reader, theSE, and a processor in one of potentially multiple form factors (hereeither within the SIM or a Secure IC), the NFC bridge chip that is usedto convert an electronic data signal to an RF data signal for anexternal reader, and the external reader that may also be used tointeract with the SE in order to retrieve banking information. Thereader in the cellular network adapter 320 may communicate to the usinga number of different methods. For example, the reader in the cellularnetwork adapter may communicate directly to the SE using ISO 7816-3 and7816-4 protocols. An external reader may also communicate to the SEthrough an NFC bridge controller. The NFC controller controls the datapaths to the RF interface as well as the data path to the SE. It isimportant to note that the interrogation of the SE can be initiated andcarried out by either the reader in the cellular network adapter 320 oran external reader as shown in the diagram in FIG. 16.

FIG. 16.1 shows the same hardware device depicted in FIG. 16 being usedfor a different application. The application in FIG. 16.1 relates tousing the same banking information stored on the SE for making a mobilepayment transaction over the wireless network. A transaction like thisis usually performed using a mobile phone connecting to a remotemerchant over a wireless network (such as a cellular network) that mayalso be using the public internet and a mobile web browser on the phoneitself. In order to deliver the transaction data from the SE to the webbrowser by the interrogator, keyboard emulation or software plug-in maybe used to populate the web browser with the appropriate data. In thecase where the transaction is not performed using a mobile web browser,the transaction information may pass to the merchant using other methodssuch as email, SMS, or other proprietary or standardized communicationmethods. The cellular network adapter 430 (the interrogator and thecommunications controller and the secure element), in this case, may becontained as an element 420 inside the mobile phone and exist as asoftware module running on the baseband of the phone. The interrogatoressentially serves the same purpose as the contactless reader shown inFIG. 16. Its job is to interrogate the SE inside the phone and build acommunication data package 400 that typically includes an encrypted panand optionally Track 1 and/or Track 2 data. In order to do this, a“Reader On Card” mechanism may be used in order to further encrypt thePAN or full Track 1 and Track 2 data for transportation over a publicnetwork using the antenna 410 of a mobile phone.

After the interrogator has completed an interrogation process that istypically similar to the interrogation routine in FIG. 14 or FIG. 5.2,the data packet to be issued for authorization is sent to the “onlinemerchant” over a wireless network. This data packet may contain fullTrack 1 and/or Track 2 information that has been encrypted or maycontain only an encrypted PAN with an expiration date. The encrypted PANis encrypted using the same method as described in FIG. 13, FIG. 13.1,FIG. 13.2, FIG. 13.3, and FIG. 13.4. After the encrypted data is passedto the “online merchant” the merchant may further submit the data justas it would a traditional card transaction to the processing network forauthorization. The processing network then routes the data to theappropriate bank for authorization as shown in FIG. 16.1. Prior to theauthorization of the data packet a “Decryption Device” interprets thedata packet, decrypts the PAN or full track data, and replaces it withthe original and legitimate PAN or track data. The decryption device mayalso perform other statistical checks on the PAN or track data such asverifying the transaction counter or timestamp is not repeated.

FIG. 16.2 shows a similar encryption technique for encrypting the cardPAN. In this case, it is possible to add a timestamp factor into theencryption of the PAN. Because a mobile phone is an electronic devicethat can keep accurate time, the interrogator would be able to use atimestamp to further randomize the initialization vector that is used toencrypt the PAN data. When this transaction data reaches the decryptiondevice on the other side of the network, the decryption device can thenuse a timestamp in a similar manner to decrypt the PAN data. It may notbe possible to use a timestamp in all embodiments if the interrogatordoes not have access to an accurate clock.

As previously indicated, various embodiments may include embedding theSE within a mobile phone or PDA. Such embodiments may use portions ofthe baseband processor of the mobile phone or PDA as a communicationscontroller and an interrogator. The combination of the SE, thecommunications controller and the interrogator then provide theprincipal components of a typical cellular network adapter. Softwarewithin the mobile phone may run the interrogation routines whileinteracting with the SE. The software may then perform communicationcontroller functions by inserting the data extracted from the SE intoappropriate areas such as SMS or email message, or form field. Theinsertion into these areas may include the keyboard emulation tacticspreviously described herein. The insertion into these areas may includeautomatic SMS or email message building and sending by software runningon the mobile phone. The automatically built SMS or email messagetypically includes the extracted data from the interrogator.

In summary, embodiments disclosed herein describe various systems andmethods for providing self-authorizing tokens and self-authorizingcellular network adapters. The foregoing descriptions of embodimentshave been presented for purposes of illustration and exposition. Theyare not intended to be exhaustive or to limit the embodiments to theprecise forms disclosed. Obvious modifications or variations arepossible in light of the above teachings. The embodiments are chosen anddescribed in an effort to provide the best illustrations of principlesand practical applications, and to thereby enable one of ordinary skillin the art to utilize the various embodiments as described and withvarious modifications as are suited to the particular use contemplated.All such modifications and variations are within the scope of theappended claims when interpreted in accordance with the breadth to whichthey are fairly, legally, and equitably entitled.

1. A token comprising: a mounting structure having a communicationconnector configured to connect to a computer terminal; a secure elementaffixed to the mounting structure, the secure element comprising a datafile, a secure element interrogator affixed to the mounting structureand configured to interrogate the secure element to acquire transactioninformation from the data file by exchanging a plurality of transactiondata communications only between the secure element and the secureelement interrogator; and a communications controller affixed to themounting structure and configured to receive the data from the secureelement interrogator and to transmit the transaction information as asingle data communication to the computer terminal through thecommunications connector.
 2. The token of claim 1 wherein the pluralityof transaction data communications comprises communications formattedaccording to ISO 7816-4.
 3. The token of claim 1 wherein the secureelement comprises personalization information that is unique to aspecific holder to whom the token is issued.
 4. The token of claim 1wherein the secure element interrogator exchanges the plurality oftransaction data communications with the secure element only withinlibraries or memory space residing on the mounting structure.
 5. Thetoken of claim 1 wherein the secure element comprises a payment cardapplication and the single data communication to the computer terminalcomprises track data.
 6. A token comprising: a mounting structure havinga communication connector configured to connect to a computer terminal;a secure element affixed to the mounting structure, the secure elementcomprising a payment card application and a a data file, a secureelement interrogator affixed to the mounting structure and configured tointerrogate the secure element to acquire transaction information fromthe data file by exchanging a plurality of transaction datacommunications only between the secure element and the secure elementinterrogator; and a communications controller affixed to the mountingstructure and configured to receive the data from the secure elementinterrogator and to transmit the transaction information as track datato the computer terminal through the communications connector.
 7. Thetoken of claim 6 wherein the plurality of transaction datacommunications comprises communications formatted according to ISO7816-4.
 8. The token of claim 6 wherein the secure element comprisespersonalization information that is unique to a specific holder to whomthe token is issued.
 9. The token of claim 6 wherein the secure elementinterrogator exchanges the plurality of transaction data communicationswith the secure element only within libraries or memory space residingon the mounting structure.
 10. The token of claim 6 wherein the trackdata is transmitted as a single data communication to the computerterminal.
 11. The token of claim 6 wherein the track data comprises fullTrack 1 and Track 2 data.
 12. A token comprising: a mounting structurehaving a communication connector configured to connect to a computerterminal; a secure element affixed to the mounting structure, the secureelement comprising a data file, a secure element interrogator affixed tothe mounting structure and configured to interrogate the secure elementto acquire transaction information from the data file by exchanging aplurality of transaction data communications only between the secureelement and the secure element interrogator; and a communicationscontroller affixed to the mounting structure and configured to receivethe data from the secure element interrogator and to transmit thetransaction information to the computer terminal through thecommunications connector.
 13. The token of claim 12 wherein theplurality of transaction data communications comprises communicationsformatted according to ISO 7816-4.
 14. The token of claim 12 wherein thesecure element comprises personalization information that is unique to aspecific holder to whom the token is issued.
 15. The token of claim 12wherein the secure element interrogator exchanges the plurality oftransaction data communications with the secure element only withinlibraries or memory space residing on the mounting structure.
 16. Thetoken of claim 12 wherein the secure element comprises a payment cardapplication and the single data communication to the computer terminalcomprises track data.
 17. A token comprising: a mounting structurehaving a communication connector configured to connect to a computerterminal; a secure element affixed to the mounting structure, the secureelement comprising a data file, a secure element interrogator affixed tothe mounting structure and configured to interrogate the secure elementto acquire transaction information from the data file by exchanging atleast one transaction data communication only between the secure elementand the secure element interrogator; and a communications controlleraffixed to the mounting structure and configured to receive the datafrom the secure element interrogator and to transmit the transactioninformation as a single data communication to the computer terminalthrough the communications connector.
 18. The token of claim 17 whereinthe at least one transaction data communication comprises communicationsformatted according to ISO 7816-4.
 19. The token of claim 17 wherein thesecure element comprises personalization information that is unique to aspecific holder to whom the token is issued.
 20. The token of claim 17wherein the secure element interrogator exchanges the at least onetransaction data communication with the secure element only withinlibraries or memory space residing on the mounting structure.
 21. Thetoken of claim 17 wherein the secure element comprises a payment cardapplication and the single data communication to the computer terminalcomprises track data.
 22. A token comprising: a mounting structurehaving a communication connector configured to connect to a computerterminal; a secure element affixed to the mounting structure, the secureelement comprising a payment card application and a data file, a secureelement interrogator affixed to the mounting structure and configured tointerrogate the secure element to acquire transaction information fromthe data file by exchanging at least one transaction data communicationonly between the secure element and the secure element interrogator; anda communications controller affixed to the mounting structure andconfigured to receive the data from the secure element interrogator andto transmit the transaction information as track data to the computerterminal through the communications connector.
 23. The token of claim 22wherein the at least one transaction data communication comprisescommunications formatted according to ISO 7816-4.
 24. The token of claim22 wherein the secure element comprises personalization information thatis unique to a specific holder to whom the token is issued.
 25. Thetoken of claim 22 wherein the secure element interrogator exchanges theat least one transaction data communication with the secure element onlywithin libraries or memory space residing on the mounting structure. 26.The token of claim 22 wherein the track data is transmitted as a singledata communication to the computer terminal.
 27. The token of claim 22wherein the track data comprises full Track 1 and Track 2 data.
 28. Atoken comprising: a mounting structure having a communication connectorconfigured to connect to a computer terminal; a secure element affixedto the mounting structure, the secure element comprising a data file, asecure element interrogator affixed to the mounting structure andconfigured to interrogate the secure element to acquire transactioninformation from the data file by exchanging at least one transactiondata communications only between the secure element and the secureelement interrogator; and a communications controller affixed to themounting structure and configured to receive the data from the secureelement interrogator and to transmit the transaction information to thecomputer terminal through the communications connector.
 29. The token ofclaim 28 wherein the at least one transaction data communicationcomprises communications formatted according to ISO 7816-4.
 30. Thetoken of claim 28 wherein the secure element comprises personalizationinformation that is unique to a specific holder to whom the token isissued.
 31. The token of claim 28 wherein the secure elementinterrogator exchanges the at least one transaction data communicationwith the secure element only within libraries or memory space residingon the mounting structure.